Subject: APPN MIB Inconsistencies with OS/2 CM

From: "Michael O. Allen (919-254-4442)" <[email-masked]>
Date: Mon, 11 Jul 94 08:51:22 EDT

Ref:  Your note of Tue, 5 Jul 1994 15:14:00 -0400 (attached)

Jim,

I agree that our lives would be easier if the enumeration values in our
MIBs and in our product APIs were identical.  However, I'm not sure
what we can practically do about it at this point in time.  SNMP
conventions prohibit -- or at least strongly discourage -- the use of
zero as an enumeration value, so we can't realistically change the MIB
enumerations to match those in CM/2, which use zero values in many
cases.  Besides, there are now several implementations of that MIB that
I am aware of, and those developers would probably not be agreeable to
a change in the MIB and their implementations just to conform to the
conventions of another product.

On the other hand, the CM/2 API was not written with this application
in mind.  It is an independent API that by now has any number of third-
party application programs written to it.  The CM/2 developers and
those third-party developers would not be agreeable to change their API
and applications just for the purpose of aligning with the conventions
of one application (SNMP MIB).

As a MIB implementer myself, I appreciate the frustration of having to
map enumerations that are *almost* the same, but at least such code is
trivial.  We can console ourselves with the knowledge that mapping our
own implementation specifics to a single MIB will make life easier for
management applications, which will not have to deal with product-
unique encodings.

With regard to the comment about ibmappnNodePortLsRole:

Architecture defines three link station roles - primary, secondary, and
negotiable.  There are two modes - normal response mode (NRM) and
asynchronous balanced mode (ABM).  The role is only significant in NRM
mode, and is unimportant in ABM mode.  So you are correct in saying
that ABM is not a valid link station role.  However, the current MIB
design to group these related values together in a single enumeration
is not necessarily an invalid approach -- it is one method to encoding
the information.  An alternative design might be to delete the value
"abm" from ibmappnNodePortLsRole, add a new object to the row
indicating the mode (NRM or ABM), and finally to add a new enumeration
value to ibmappnNodePortLsRole indicating "notApplicableForAbm".
However, I have to point out that this is simply an alternative way to
represent exactly the same information.  Do you have another
suggestion?

Regards,
Mike

----------------------------- Note follows ------------------------------
X400-Received:
 by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Jul 1994 20:11:17 -0400
X400-Received:
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Jul 1994 16:19:00 -0400
X400-Received:
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 5 Jul 1994 15:14:00 -0400
Date:  Tue, 5 Jul 1994 15:14:00 -0400
X400-Originator:  /dd.id=1582804/g=jim/i=j/s=cobban/@bnr.ca
X400-Mts-Identifier:
 [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.615:05.06.94.20.19.00]
X400-Content-Type:  P2-1984 (2)
Content-Identifier:  APPN MIB Inco...
From: "jim (j.) cobban" <[email-masked]>
Sender: "jim (j.) cobban" <[email-masked]>
To: [email-masked]
Cc: "denis (d.r.) fortier" <[email-masked]>,
        "eddy (e.n.y.) ko" <[email-masked]>, "william (w.l.) yue" <[email-masked]>,
        "richard (r.s.h.) lam" <[email-masked]>,
        "jenson (j.c.) wong" <[email-masked]>, [email-masked],
        [email-masked]
Subject:  APPN MIB Inconsistencies with OS/2 CM

In our management interface we have a requirement to support both the SNMP
management interface, based on the current 6611 MIB, and another interface
which is based on the OS/2 CM interface.  One concern we have is that these
two interfaces use different encodings of the enumerated values of
attributes.  There is no obvious reason why two different encodings should be
used, and it would simplify my implementation if the two interfaces were
the same.

1) The following APPN MIB constants are defined differently in CM.
   APPN MIB     CM
   yes(1)   --  yes (1)
   no(2)    --  no (0)

2) The following APPN MIB constants are defined differently in CM.

   ibmappnNodeType
   networkNode(1)  -- NN=1
   endNode(2)      -- EN=0
   len(4)          -- LEN=2

3) The following APPN MIB constants are defined differently in CM.

   ibmappnNodeLsDlcType
   ibmappnNodePortDlcType
   other(1) --  X25=1
   sdlc(2) -- SDLC=0
   dls(3)
   socket(4)
   ethernet(5)
   tokenRing(6) -- 8022=2

4) The following APPN MIB constants are defined differently in CM.

   ibmappnNodeLsState
   ibmappnNodePortState
   inactive(1)        -- Inactive=0,
   pendactive(2)      -- PendingActive=1,
   active(3)          -- Active=2
   pendinact(4)       -- PendingInactive=3

5) The following APPN MIB constants are defined differently in CM.

   ibmappnNnAdjNodeCpCpSessStatus
   active(1)                      -- ACTIVE=1
   conLoserActive(2)
   conWinnerActive(3)
   inactive(4)                    -- INACTIVE=0

6) The following APPN MIB constants are defined differently in CM.

   ibmappnNnNodeType
   networknode(1)    -- NN=0,
   virtualnode(3)    -- VRN=1

7) The following APPN MIB constants are defined differently in CM.

   ibmappnDirLuLocation
   local(1) -- LOCAL=0,
   domain(2) -- DOMAIN=1
   xdomain(3) -- XDOMAIN=2

8) The following APPN MIB constants are defined differently in CM.

   ibmappnDirType
   home(1)        -- HOME=0,
   cache(2)       -- CACHE=1
   registered(3)  -- REGISTERED=2

9) The following APPN MIB constants are defined differently in CM.

   ibmappnNodePortPortType
   leased(1)               -- NONSW=0
   switched(2)             -- SW=1
   sharedAccessFacilities(3  --  SATF=2

10) The following APPN MIB constants are defined differently in CM.

   ibmappnNodePortLsRole
   primary(1)             --  PRI=0,
   secondary(2)           --  SEC=1
   negotiable(3)          --  NEG=3
   abm(4)                 --  ???    <- not defined in CM

   abm is not orthogonal to the other values and probably should not
   appear in the MIB.

---

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 11 Jul 1994 11:35:00 -0400

In message "APPN MIB Inconsistencies with OS/2 CM", 

>represent exactly the same information.  Do you have another

I don't know about your implementations, but the information which the MIB
requires me to present at this point simply does not exist in my
implementation.  Given an SNMP verb I issue NOF verbs, and the NOF QUERY_PORT
verb does not provide a distinction between NRM and ABM (reference page 3-41
of the APPN AR).  The SNMP MIB should not demand that an implementation
return values which are not defined in the architecture of reference.  There
is nothing in the APPN architecture of reference which declares that the
roles primary, secondary, and negotiable are not applicable to ABM.  Indeed if
you do not follow the negotiation procedure for link role on a TRN you will
not get very far. 

Therefore I feel that the ABM role value for ibmappnNodePortLsRole should be
removed from the draft MIB.  There should be no additional object or
alternative enumeration values for ibmappnNodePortLsRole, because such an
alternative would be inconsistent with the APPN architecture of reference.

As to the other enumerations I continue to have problems, and I would like to
hear the opinions of other members of the SIG as to whether these
inconsistencies are reasonable.

I thought this was a draft MIB and not part of the APPN architecture of
reference.  Under our license agreements we are not permitted to ship
products which implement portions of the architecture until those portions
achieve closed pages status.  Therefore anyone who has shipped an
implementation of this MIB is in violation of their license, and if the SIG
should choose to change the enumeration values between now and closed pages
time that it is the right of the SIG.

Has there been any discussion of moving the anchor point of this MIB?  I am
not shipping an ibm6611 and would prefer not to have to pretend that I was.

Unless this mail exploder has been VERY quiet the last couple of months, I
must assume that it has not been forwarding any of the correspondence to me
since the move to networking.cary.ibm.com.  I have not received anything in
several weeks that was not specifically addressed to me.  In particular I do
not receive back a copy of my own posts, as I did when the exploders were on
ibmstandards.